Diagrama de comunicació

Un diagrama de comunicació (anomenat diagrama de col·laboració a UML 1.0) és una forma de representar la interacció entre objectes pròpia del llenguatge UML 2.0. De la mateixa manera que els diagrames de seqüència, serveixen per representar un cas d'ús de manera visual. La principal diferencia entre els diagrames de comunicació i els de seqüència. Els primers se centren a representar els rols dels objectes i els segons en representar el temps en el qual s'envien els missatges, de manera que certs casos d'ús seran més fàcils d'entendre. Tot i això és senzill passar d'un a l'altre.

Els diagrames de comunicació són una ajuda visual que descriu amb el detall necessari el flux principal i els fluxos alternatius. El seu objectiu principal és veure si els casos d'ús tenen un esquema apropiat que faci que la interacció amb l'actor condueixi al resultat esperat. Això es pot comprovar fàcilment veient l'esquema, ja que un esquema simple implicarà un comportament també simple. A més, la implementació del codi serà més senzilla veient el diagrama, ja que, per exemple, es veuen clarament les connexions entre objectes i mostra els aspectes dinàmics d'un sistema. D'altra banda, en casos on l'ordre dels missatges sigui complicat o hi hagi molts condicionals i bucles serà més recomanable utilitzar un diagrama de seqüència, ja que aquests representen millor aquests aspectes.

Elements

Per representar certs processos es fan servir certs procediments generalitzats. Això es fa per tal de garantir que qualsevol persona pot entendre de la mateixa manera un mateix diagrama.

Objectes

De dalt a baix i d'esquerra a dreta, un objecte, dues llistes d'objectes, un objecte de control i un objecte de pantalla dibuixats en UML.

Tots els objectes que no siguin de control o d'interfície seran representats amb un rectangle dins del qual hi haurà el nom de la classe a la qual pertanyen precedit de dos punts. Els noms de les classes també haurien d'estar subratllats, però és un costum bastant generalitzat només posar els dos punts, ja que amb això ja n'hi ha suficient per saber que es tracta d'un objecte.

En cas que necessitem referir-nos a un objecte en concret en algun punt de l'execució podem posar un nom a l'objecte en concret escrivint-lo abans dels dos punts. Aquest ha de ser únic en tota la funció.

Objecte de control

Els objectes de classes de control són representats amb un cercle amb una fletxa a la part superior. A més, tenen el nom a sota amb els dos punts a davant. Com a mínim, sempre n'hi haurà una per cada cas d'ús, ja que representen la classe de control de l'aplicació i per tant és la que relaciona la interfície d'usuari amb els objectes principals, els quals, per la seva banda, estaran relacionats amb els objectes més secundaris.

Objecte de frontera

Els objectes de les classes de frontera són representats amb un cercle amb una T girada 90° en la direcció contrària al rellotge a la banda esquerre. Representen la interfície de l'aplicació i per tant són els que relacionen els actors amb els objectes de control, raó per la qual cada actor n'hauria de tenir una, tot i que poden ser compartides entre actors i diferents casos d'ús. També és possible que un sol cas d'ús tingui més d'un objecte frontera si, per exemple, es mostra per diferents finestres.

Llistes d'objectes

En el cas d'utilitzar llistes d'objectes es representaran de la mateixa manera que la resta d'objectes però amb els símbols [*] després del nom de la classe. Una altra opció serà dibuixar altres rectangles darrere de l'original.

Cal notar que aquests objectes no tindran els mètodes corresponents a la classe corresponent original sinó que tindran els corresponents a una llista o conjunt.

Actors

Actor en UML

Els actors són representats per una figura humana representada amb pals i tenen el nom a sota. Representen allò que activa la funció i que pot ser una persona, un conjunt de persones, un element extern o fins i tot conceptes abstractes com el temps. De fet, encara que es tracti de persones, no s'ha d'entendre com una persona concreta sinó com un concepte, ja que una mateixa persona pot fer accions representant diferents actors, moment en què direm que té diferents rols. Per exemple, una persona pot representar l'actor de gerent d'un supermercat però això no impedeix que després pugui representar el paper de client.

Tal com passa a la realitat els actors només poden interactuar amb l'objecte que representa la interfície, de manera que els actors sempre tindran comunicacions amb l'objecte pantalla.

Comunicació

A l'esquerra un objecte que té una comunicació amb la llista d'objectes de la dreta. A més, efectua la crida número 3.1 que s'anomena Buscar. Aquesta passa el valor anomenat codi i retorna el p.

Per representar comunicacions o enllaços entre dos objectes es fa servir una línia sense cap fletxa en cap de les direccions. Això vol dir que els objectes tenen una interacció directe durant l'execució de la funció, és a dir, que s'envien algun missatge.

Ordre d'execució

Per representar l'ordre d'execució s'utilitzen nombres naturals en les crides de procediments. La primera crida serà la que tingui el número més baix (que generalment serà la 1) i la següent serà el següent número fins a arribar al màxim.

En cas de desitjar-ho el creador del diagrama pot afegir nombres entre els nombres naturals afegint un altre nombre després d'un punt. Aquests també seguiran l'ordre natural. D'aquesta manera entre els números 1 i 2 hi haurà 1.1, 1.2, 1.3, ..., en aquest ordre. Això també es pot repetir tantes vegades com es vulgui, és a dir, entre 1.1 i 1.2 també hi ha 1.1.1, 1.1.2, 1.1.3, ...

Missatge

Per representar l'enviament d'un missatge o la crida a un procediment s'escriu el nom del procediment després del número que indica l'ordre d'execució i entre parèntesis els arguments que li passem. Per representar quin objecte crida a quin afegirem una fletxa al costat o a sobre del número que indica l'ordre d'execució. Aquesta fletxa apuntarà de la posició on hi ha l'objecte que ha iniciat la crida a la posició on hi ha l'objecte que la rep.

Per poder realitzar una crida es necessita una comunicació entre els dos objectes, al costat de la qual escriurem la crida al procediment.

En cas de desitjar utilitzar el resultat retornat per la crida en algun altre lloc de la funció podem posar un nom seguit d'un igual abans del nom del procediment.

Bucles

Si volem representar que una crida es realitza més d'una vegada en un bucle ho podem fer si afegim *[...] entre el número d'operació i el nom de la crida i especificant entre els claudàtors com saber el nombre de vegades que hem d'iterar. Se suposa que les crides fetes a resultat de la crida on fem el bucle també es realitzen una vegada per iteració.

Crides concurrents

També podem decidir executar totes les crides del bucle en paral·lel. En aquest cas farem igual que en el bucle però afegint dues barres entre l'asterisc i el claudàtor, d'aquesta manera: *||[...].

Condicionals

En el cas que només vulguem realitzar una certa crida si es compleix una certa condició ho podem especificar posant uns claudàtors entre els quals escriurem quina és la condició que permet o impedeix que la crida s'efectuï. També es suposa que les crides fetes a resultat de la crida on apareix el condicional només es realitzen si aquesta ho fa.

Exemple de creació

Per poder crear un diagrama de comunicació sempre utilitzarem una fitxa de cas d'ús i d'un diagrama de classes com a base. Suposem el cas en el qual hem de crear el diagrama de comunicació mostrat a l'apartat d'elements. Primer de tot necessitarem la fitxa de cas d'ús anomenada crear llibre, i el diagrama de classes del problema:

Pas numero 2

Pas 1

Primer de tot, per poder crear el diagrama de comunicació el primer que farem serà identificar quines classes prendran part en aquest cas d'ús i un cop triades, començarem a crear el diagrama de comunicació. Per poder triar quines classes seran necessàries haurem de localitzar de quines classes serà necessari llegir o escriure dades, a l'igual d'aquelles que necessitarem accedir per arribar a les anteriors.

També necessitarem les classes de llista Exemplars (Exemplar[*]) i llista Reserves (Reserva[*]), les quals farem servir per crear llistes buides dels seus respectius elements.

• Classes del nostre cas d'ús: Llibre, Exemplar[*], Reserva[*], RelLlibres, Llibre[*].

Pas 2

Pas numero 3

Un cop temin clares les classes, afegirem com a elements principals l'actor que realitzarà el cas d'ús, la interfície des de la que el realitzarà (Ex:interfície gràfica que pot tractar-se d'un Ordinador, mòbil, terminal, ...), la qual mostrarà a l'actor la informació corresponent, i l'element de control del problema.

Pas 3

Un cop fet el pas anterior, afegirem les diferents classes que creiem que faran falta per poder realitzar en el diagrama de comunicació, el que hi ha descrit a la fitxa de cas d'ús.

Pas 4

Un cop tenim ja tots els elements i classes dibuixades, transformarem les operacions de la fitxa de cas d'ús en instruccions realitzables en el nostre diagrama de comunicació, tenint en compte que començarem l'execució des de la localització de l'actor, i que sempre haurem d'accedir a classes que estiguin immediatament connectades entre elles. Aquesta transformació es farà de la mateixa forma en què es faria en un diagrama de seqüència donat que els dos diagrames comparteixen les mateixes operacions.

Ara que ja tenim plantejades les operacions que necessitarem, començarem a unir les classes del diagrama de seqüències segons les nostres necessitats, tenint en compte que dos classes només poden anar unides si estan unides també en el diagrama declasses.

Quan ja ho tinguem tot fet, escriurem les operacions necessàries a sobre de les seves respectives unions seguides d'una fletxa indicant la direcció de l'operació, i ja tindrem el diagrama de comunicació acabat.